The present specification relates to data processing, and more particularly to client-server applications.
Client-server applications typically have two components: a server or back-end component that provides the application logic, and a client or front-end component through which a user interacts with the application. The server component, which is sometimes referred to simply as the application itself, is usually executed on a computer that is specifically configured as a server. The server computer may have resources that provide high computational and network bandwidth, for example, so that it can execute multiple applications that interact with numerous clients. The client component can be executed on a separate computer, although in some instances the server component and the client component may be executed on the same computer. In this specification, a program is said to be executed whether the program is compiled or interpreted.
Server computers typically provide a specific platform that can be used to execute applications written in a corresponding language. For example, a server computer may be configured to provide a Java 2, Enterprise Edition (J2EE) platform that can be used to execute Java applications. Other examples of platforms include Microsoft's .NET platform, which can be used to execute applications written in C#, and SAP's Advanced Business Application Programming Language (ABAP) platform, which can be used to execute ABAP applications.
Platforms generally provide a framework within which applications execute. Among other things, a framework provides controls, which are elements through which a user interacts with, provides input to, or controls an application. For example, a control can be a button that allows a user to activate a certain feature, a radio button that allows the user to select one of several choices, a textbox that allows the user to enter some input, or a checkbox that allows the user to select or de-select an option.
The framework provided on a specific platform usually includes variables or objects to store the server side state of controls, control logic that specifies how the controls operate, and rendering logic that specifies how the controls should be rendered on the client component of an application. The control logic for a checkbox, for example, can specify that the value of a variable that represents the checkbox should toggle between “true” and “false” as the user clicks on the checkbox. The rendering logic for the checkbox, on the other hand, can specify that the checkbox should be rendered as an empty square or as a square with a checkmark in it depending on the state of the corresponding variable. Rendering logic is often provided in the form of a function or a class of functions that convert the state of a control into code that can be used to render the control on a client component. For example, rendering logic can produce markup language such as Hypertext Markup Language (HTML) code for rendering a control on a client browser, or Wireless Markup Language (WML) code for rendering the control on a wireless client interface.
Although applications are usually written in one language and executed on one platform, they are frequently ported into multiple languages and executed on multiple platforms. Such porting can make applications available to more customers, but it can also create additional maintenance work. One example of such maintenance work occurs when a company decides to change the “look” of its applications. For instance, a company can decide that when a checkbox is selected, the corresponding text for the checkbox should always be rendered in boldface font. In such a scenario, the company would have to modify the appropriate control rendering logic for every platform and framework on which its applications execute.